Processors often exchange data over a bi-directional bus to communicate with other devices and other processors. Many bus protocols require the slave processor to respond to communications initiated by the master processor on the bus and do not provide for a mechanism for the slave processor to initiate a transaction. Accordingly, the slave processor can only participate in a transaction after being polled by a master processor. In many arrangements, a separate interrupt line is provided between the master processor and the slave processor to allow the slave to initiate a transaction with the master. Bus protocols typically include a signaling mechanism to alert other devices on the bus that a transmission will occur. As discussed in further detail below, for example, I2C bus protocols provide for a particular sequence of high and low levels on the two conductors of the I2C bus to form a START signal that indicates the beginning of a transmission.
For exchanging data through the bus, slave devices include a bus interface that can be implemented using hardware, firmware and/or software. Implementations using firmware and/or software (collectively referred to herein as “non-hardware implementations”) are significantly less expensive than hardware bus interfaces. The non-hardware implementations, however, are limited in that the adequate resources to detect a start condition on the bus typically cannot be allocated for continuously monitoring the bus. Accordingly, transactions initiated by the master processor may go undetected by the slave processor. One possible implementation for avoiding this situation includes implementing a second interrupt line between the master and the slave to allow the master to signal the slave that a transaction will occur. Such implementations have the significant disadvantage of requiring an additional wire or connection between the master and slave.
Accordingly, there is a need for bi-directional single conductor interrupt line.